IP Multimedia services provide a dynamic combination of voice, video, messaging, data, etc. within the same session. By growing the number of basic applications and the media which it is possible to combine, the number of services offered to the end users will grow, and the inter-personal communication experience will be enriched. This will lead to a new generation of personalised, rich multimedia communication services, including so-called “combinational IP Multimedia” services.
The UMTS (Universal Mobile Telecommunications System) is a third generation wireless system designed to provide higher data rates and enhanced services to users. UMTS is a successor to the Global System for Mobile Communications (GSM), with an important evolutionary step between GSM and UMTS being the General Packet Radio Service (GPRS). GPRS introduces packet switching into the GSM core network and allows direct access to packet data networks (PDNs). This enables high-data rate packets switch transmissions well beyond the 64 kbps limit of ISDN through the GSM call network, which is a necessity for UMTS data transmission rates of up to 2 Mbps. UMTS is standardised by the 3rd Generation Partnership Project (3GPP) which is a conglomeration of regional standards bodies such as the European Telecommunication Standards Institute (ETSI), the Association of Radio Industry Businesses (ARIB) and others. See 3GPP TS 23.002 for more details.
The UMTS architecture includes a subsystem known as the IP Multimedia Subsystem (IMS) for supporting traditional telephony as well as new IP multimedia services (3GPP TS 22.228, TS 23.228, TS 24.229, TS 29.228, TS 29.229, TS 29.328 and TS 29.329 Releases 5 to 7). IMS provides key features to enrich the end-user person-to-person communication experience through the use of standardised IMS Service Enablers, which facilitate new rich person-to-person (client-to-client) communication services as well as person-to-content (client-to-server) services over IP-based networks. The IMS is able to connect to both PSTN/ISDN (Public Switched Telephone Network/Integrated Services Digital Network) as well as the Internet.
The IMS makes use of the Session Initiation Protocol (SIP) to set up and control calls or sessions between user terminals (or terminals and application servers). The Session Description Protocol (SDP), carried by SIP signalling, is used to describe and negotiate the media components of the session. Whilst SIP was created as a user-to-user protocol, IMS allows operators and service providers to control user access to services and to charge users accordingly. The 3GPP has chosen SIP for signalling between a User Equipment (UE) and the IMS as well as between the components within the IMS.
By way of example, FIG. 1 illustrates schematically how the IMS fits into the mobile network architecture in the case of a GPRS/PS access network (IMS can of course operate over other access networks). Call/Session Control Functions (CSCFs) operate as SIP proxies within the IMS. The 3GPP architecture defines three types of CSCFs: the Proxy CSCF (P-CSCF) which is the first point of contact within the IMS for a SIP terminal; the Serving CSCF (S-CSCF) which provides services to the user that the user is subscribed to; and the Interrogating CSCF (I-CSCF) whose role is to identify the correct S-CSCF and to forward to that S-CSCF a request received from a SIP terminal via a P-CSCF.
Within the IMS service network, Application Servers (ASs) are provided for implementing IMS service functionality. Application Servers provide services to end users in an IMS system, and may be connected either as end-points over the 3GPP defined Mr interface, or “linked in” by an S-CSCF over the 3GPP defined ISC interface. In the latter case, Initial Filter Criteria (IFC) are used by an S-CSCF to determine which Applications Servers should be “linked in” during a SIP Session establishment (or indeed for the purpose of any SIP method, session or non-session related). The IFCs are received by the S-CSCF from an HSS during the IMS registration procedure as part of a user's Subscriber Profile.
The user-specific information related to the services provided by ASs is stored in XML document format. A Ut interface (or “reference point”) has been specified between ASs and user terminals (TS23.002) that allows a user terminal to operate as an XML Document Management Client (XDMC) in order to manipulate the XML documents, therefore allowing users to define how their services are provisioned.
ETSI TISPAN has adopted the XML Configuration Access Protocol (XCAP), as specified in IETF RFC4825, for use over the Ut interface and which facilitates the use of HTTP methods, i.e. GET, PUT, and DELETE, on the elements and attributes of an XML document as identified by a Request-URI. ETSI 183 023 presents a refined XCAP protocol for manipulating data relating specifically to PSTN/ISDN simulation services that will be provisioned within Next Generation Networks (NGN).
Each application or service that makes use of XCAP defines its own XCAP application usage. The application usage for a service defines an ID for the application usage, the structure of the XML document or a fragment of the XML document that for that service, using an XML schema, as well as defining other key pieces of information. The XML schema defines the elements and attributes of an XML document and the data type for those elements and attributes. An XML document will contain a reference to a file containing the XML schema for that document. 3GPP TS24.623 defines an application usage for supplementary services. The simservs XML document contains the data associated with one or more supplementary services, and the XML schema for this document defines the structure as comprising of a common part and a number of XML fragments corresponding to each of the supplementary services. Each XML fragment affects the settings of a supplementary service (or group of services).
XML documents are handled by XML Document Management Servers (XDMS) which are typically implemented in or co-located with ASs. For example, an XDMS responsible for handling service data relating to Multimedia Telephony (MMTel) services might be co-located with a Multimedia Telephony Application Server (MTAS). An XDMS is a HTTP origin server that manipulates the elements and attributes of an XML document according to the conventions described in RFC4825. In use, an XDMS stores service data into the HSS (as transparent data) which is then retrieved by the AS at service invocation.
FIG. 2 illustrates schematically the IMS XML document management network. The XML documents defining customer services and settings are handled by the AS/XDMS 1. The Sh interface allows the XDMS to communicate with the Home Subscriber Server (HSS) 2. A provisioning system 3 allows a network operator to initially install pre-configured XML documents, based upon the standardised XML schema, on a per-user basis into the HSS, and to subsequently amend the installed XML documents via the XDMS. The management network additionally provides a mechanism whereby a user can edit his/her associated XML document. For this purpose, a Ut client 4 is installed within the user terminal. As discussed above, the Ut client uses the XCAP protocol to retrieve (either the whole document or a fragment thereof) and amend the XML documents (or fragment). It will be appreciated that the XDMS reacts to a retrieval request from a UE by obtaining the relevant XML documents or fragment from the HSS and delivering this to the UE over the Ut interface.
An Aggregation Proxy (AP) 5 is arranged to “intercept” XCAP traffic flowing between the Ut client 4 and the XDMS. The role of the AP is firstly to authenticate user originating requests and in particular to determine if a particular user has the right to access the XDMS. Secondly, the AP provides a common point of connection for a Ut client, distributing XCAP requests to appropriate XDMSs.
The Ut client fetches the stored data from the XDMS by sending a XCAP GET request to the XDMS over the Ut interface (assuming authorisation by the AP and redirection by any aggregation point). The XDMS fetches the data from the HSS over the Sh interface and sends it back to the Ut client in a Ut response message. The Ut client displays information and options to the user via a Graphical User Interface (GUI).